InfoMagic Internet Tools 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / ip / ppp / dp-2.3 / doc / DialupPPP next >

Wrap

Text File | 1993-01-27 | 74.5 KB | 1,892 lines

Dialup PPP Release 2.3 Kirk Smith Purdue University January 1993 1. Introduction 1.1 General This software was developed to provide dialup on demand PPP over high speed modems. In many situations, leased lines are used to provide TCP/IP links over significant distances. With the advent of V.32bis modems, and with this software, another alternative exists. It appears to the application that the modems remain connected all the time (like a leased line). In reality, however, they disconnect whenever there is no traffic. When a packet arrives at the interface to be transmitted, and the modems are not connected, a connection is made and the packets begin to flow again. 1.2 Audience This file contains information for those intending to install and use dp (Dialup PPP), and is not aimed at teaching you about TCP/IP networking, although subjects which may be new to you such as routing and nameservers will be covered. 1.3 History The base for this software is several other free packages that have been modified to support this purpose. The dialup code came from the BBN Dialup Slip. The PPP program is from Carnegie Mellon University. The kernel PPP streams driver came from Brad K. Clements. The TCP/IP header compression support came from Van Jacobson from the University of California. Kirk Smith at Purdue University assembled all these pieces, made them all work together, and added a number of features beyond the original software. 1.4 Release Notes 1.4.1 Supported Platforms The software has been running on SunOS 4.1.1 and 4.1.2 and works quite well. It will probably not work on anything but SunOS4 (Solaris 1.0). It relies on STREAMS support. It is possible to make it work in a non-streams environment, but this has not done that. The latest version of the PPP (non-dial on demand) has support for 386BSD, and this platform may be supported soon. 1.5 Commercial Software Companies sell products that do things similar to this. I believe that this software incorporates some unique features and has value in itself. However, if you want a supported product, you might want to shop around. Morning Star Technologies is one company that I know of. Try sending mail to marketing@morningstar.com for more information. From what I can tell, they have a top notch product and top notch support. A mailing list "dplist@phoenix.acn.purdue.edu" is available. To subscribe to this list, send a message to "dplist-request@phoenix.acn.purdue.edu". This list is a group of people either using or thinking about using this software. 2. Operational Overview The software known as Dialup PPP (or dp-2.3) consists of several distinct modules. This section will discuss how the modules fit together and then will describe each module in more detail. From the application standpoint, this software implements a network interface. Ethernet interfaces have names like ie0, le0, or le1, etc. This interface has a name like dp0, dp1, dp2, etc. While ethernets are "Broadcast" networks, these is a "Point to Point" networks. This is important to consider when dealing with address assignment and routing. In short, when you "ifconfig" a point to point interface, you must provide an IP address for both the source and destination. Routes to the network never exist, but routes to both ends of the interface may exist. For more information on this, refer to the manual pages on ifconfig(8c), route(8c), and routed(8c). This network is always "UP" from the perspective of "ifconfig". Under normal conditions, network applications like "telnet" or "ftp" will always see a network that is up, even if there is a slight delay while modems are re-connected. 2.1 File Location Configuration Earlier versions of Dialup PPP placed files in very specific places. dp-2.3 allows flexible placement of files. The only really fixed file is /etc/dp.conf. It basically contains a list of pathnames for standard things. It looks like this: # # Config file for Dialup PPP. # # This file specifies the paths where all the related PPP files and # programs are located. # DPCONF_DIR=/etc/dp # System Specific Files DPLOG_DIR=/var/adm/dp # Log Files and Other Writeable Files DPPID_DIR=${DPLOG_DIR}/Pid # Files for Process IDs DPTRACE_DIR=${DPLOG_DIR}/Trace # Trace Files DPROTARY_DIR=${DPLOG_DIR}/Rotary # Rotary Files DP_DIR=/usr/dp # Common Files for All Systems DPBIN_DIR=${DP_DIR}/bin # Programs DPSCRIPT_DIR=${DP_DIR}/script # Standard Dialing Scripts DPACCESS_DIR=${DP_DIR}/access # Standard Access Files DPAUX_DIR=${DP_DIR}/aux # Auxilliary Programs DPMODEM_DIR=${DP_DIR}/modem # Modem Support Programs DPMODULE_DIR=${DP_DIR}/modules # Kernel Modules The DPCONF_DIR typically contains files that are specific to a given system. The "${DPCONF_DIR}/conf" file contains the bulk of the interface configuration. In addition, script and access files specific to a single system can be placed in this directory. The DPLOG_DIR contains log files and files that get written frequently. It has a few subdirectories that contain files that store current status. The other directories should be relatively static from one machine to the next. The default configuration file groups them all under ${DP_DIR}. This can be changed to suit local needs. In the remainder of this document, we will refer to directories by their symbolic name such as ${DPXXX_DIR} since the location will typically vary from system to system. 2.2 Normal Operation If the modems are connected, this network interface looks like a dedicated leased line Point to Point interface. Packets flow from the kernel networking software to the appropriate "dp" interface. The kernel driver for that interface consists primarily of the "dpif" streams module. The packets then become streams messages and are passed to the "pppasync" module. This module encapsulates the packets according to the PPP specification, including the addition of a frame check sum. It then passes the packets on to the streams driver of the particular serial port hardware. The serial hardware passes the byte stream onto the modem and out into the public telephone system. In addition, packets can be sent from the user level PPP program (called dp). These packets are sent through the "dpif" streams module and on to the "pppasync" module where they are encapsulated, checksummed, and passed to the serial port streams hardware to the modem. On the other end, incoming bytes are received by the serial port streams driver and passed on to the "pppasync" streams module. This module collects the bytes together into packets and rejects packets with bad checksums according to the PPP specification. Then, packets are passed on to the "dpif" streams module where they are identified as being either IP packets or control packets. IP packets are passed through the "dp" interface to the kernel TCP/IP modules. PPP control packets are passed off to a user level PPP process for further interpretation. This series of modules basically multiplexes and demultiplexes packets from the PPP programs and the kernel networking on both ends. 2.3 Establishing Modem Connections Assume, for now, that the network is properly configured, and the modems are not currently connected. When packets arrive at the interface to be transmitted to the other end, there is no "dpif" stream associated with the interface. There is no specific serial port associated with the network interface at this time. This corresponds to the DISCON (disconnected) state. The packet is placed in a network queue awaiting a successful connection. A request is assembled for this packet. The request is a separate streams message which includes the interface name, the interface unit number, a flag indicating to check authorization, the destination address, a copy of the IP header and the next 4 bytes of the packet. In both TCP and UDP, these next 4 bytes indicate source and destination ports. This request is sent to a user level program called "dpd" (Dialup PPP Daemon) through another streams device accessed through "/dev/dp0". If "dpd" is not running or not accepting messages on "/dev/dp0", then the networking code immediately returns ENETDOWN (network down). Otherwise, the WAITING state is entered and packets continue to be queued until the call completes. When the "dpd" program is started, it reads the configuration file "${DPCONF_DIR}/conf". This contains information about each network interface and each available modem. So, when the request arrives, the "dpd" program checks for authorization according to the interface configuration. If a call is not permitted, a FAILURE status is returned to the network interface. Otherwise, dpd reports a CALL_IN_PROGRESS status and creates a child process to handle this call. An appropriate modem is selected according to the configuration (this will be explained in more detail later), and the call is placed using the appropriate dial script. Once the call completes, the appropriate login script is used to log into the remote computer. A special account is set up on the remote computer that uses the login shell "${DPBIN_DIR}/dplogin". This program reads the configuration in "${DPCONF_DIR}/conf", performs simple synchronization with the "dpd" at the other end and sets the call status to CALL_IN_PROGRESS. Both the "dpd" and "dplogin" programs start the "${DPBIN_DIR}/dp" program on both ends. They negotiate all the options according to their own configuration. Once they have completed their negotiations, they report the SUCCESS call status and mark the network interfaces as ACTIVE. If a call FAILURE status is reported, or a call wait timeout expires, the interface is marked with FAILEDCALL status. After an appropriate timeout, the interface moves back to a DISCON status. This enforces a minimum time between call attempts. However, if the call failed because no modem was available, dpd reports a special NO_MODEM status which is similar to FAILURE status except the interface immediately moves to the DISCON status so that further call attempts can be made. 2.4 Timing Out Modem Connections Several timeouts can be specified in the configuration file "${DPCONF_DIR}/dp-conf". Among those are the timeouts which govern when the modems should be disconnected. These timeouts are handled by the kernel "dpif" module. When the kernel decides to disconnect a given interface, it sends a hangup signal (SIGHUP) to the "dp" process which shuts down the link. The operation of each timer will be described. Each timeout is given in seconds and is specified in the configuration file. We have found that this particular combination of timers is highly effective in our typical use. It allows reasonable timeouts for interactive use, while quickly timing out calls that were made for batch operations. 2.4.1 Inactivity Timer The simplest timeout mechanism is the inactivity timeout. If no packets have been sent or received within a given time interval, then the modems are disconnected. This is usually relatively long, roughly on the order of 2 to 3 minutes. 2.4.2 TCP Close Timer The kernel keeps track of TCP/IP connections. Each TCP/IP connection is characterized by a distinct source and destination address and port. During the life of a TCP/IP connection, packets are exchanged with certain bits set in the header to indicate the creation and deletion of these logical connections. The interesting parts of the header are the SYN, FIN, and RST bits. The software monitors the TCP/IP connections in progress. By noting the passage of SYN, FIN, and RST bits in TCP/IP headers, we keep a count of the number of active TCP/IP connections. When that connection count goes to zero, we assume that everyone has finished using the network interface for now, and a fast timeout is enabled. This shorter timeout will disconnect the modems if no packets are sent or received over an interval shorter than the normal inactivity timeouts. We have set this interval as small as 5 seconds and it works quite well 2.4.3 Non TCP Timer Not every network application uses TCP, so consideration is made for that case. In the case of no TCP connections, but non-TCP traffic is flowing, a separate inactivity timeout can be specified. This is usually on the same order as the TCP Close timer, but perhaps a little longer depending on the applications in use. 3. Source Code Overview 3.1 "conf" directory This directory contains the /etc/dp.conf file and related files. Before running make install, the dp.conf file should be edited as appropriate for your system. This directory also contains examples of ${DPCONF_DIR}/conf. "conf.hub" is an example of a central machine with several dp interfaces and a few modems. "conf.leaf" is an example of a machine with one dp interface and one modem. 3.2 "h" directory This directory contains include files that are used by several of the programs that comprise this distribution. The files dp_str.h, if_ppp.h, ppp_str.h, slcompress.h, and slip_var.h need to be copied to /usr/sys/sys as part of the kernel build procedure. 3.3 "dp" directory This directory contains a slightly modified version of the CMU PPP code. In release 2.0, it was based on "ppp" patch level 4, but under release 2.3, it is based on "ppp" patch level 6. The modifications to the standard PPP are small, but are necessary for this mode of operation. The "dp" program takes all the flags that apply to the "ppp" program. In addition, if the "dialup" flag is given to dp, it modifies the behavior in the following ways: - The name of the network interface is dp0, dp1, etc., instead of ppp0, ppp1, etc. - When an interface is brought up, it executes a SIOCCALLSTAT ioctl which is specific to the dialup PPP software. - When a normal PPP interface is brought down, it marks the network interface as DOWN and removes the appropriate route. For dialup PPP interfaces, however, the interface always appears to be UP and the route remains installed. 3.4 "dpd" directory This is originally based on the diald program from BBN. It has been heavily modified to handle PPP rather than slip, and to handle the different kernel interfaces. This section will describe the major differences in functionality. The BBN code had a good expect script capability for doing the dialing. This capability has been expanded somewhat to allow better error handling. The "recv" directive has been modified to accept any number of alternative strings. One use this to accept all known return codes from the modem. In addition, the timeout value on the "recv" can now take on a value of 0. This means to only receive input that has been already received when the "recv" is executed. Use of a "replay" followed by a "recv "string" 0" will immediately either succeed or fail based on input received since the last "mark". An example of this is the following: mark { alternate recv "CONNECT" "BUSY" "NO CARRIER" 30 alternate log "Modem Timeout" abort } { alternate replay recv "CONNECT" 0 go alternate replay recv "BUSY" 0 log "Busy" abort alternate replay recv "NO CARRIER" 0 log "No Carrier" abort } This segment of a script will wait up to 30 seconds to accept either "CONNECT", "BUSY", or "NO CARRIER", then immediately do the correct branch. This was impossible to handle in a timely way using the original code. The connection requests sent from the kernel to the "dpd" program can include more than the IP header. This was done to accommodate any future enhancements that would screen connection requests based on TCP or UDP port numbers. The uucp locking conventions have been updated to match those in use by the Sun version of uucp. This is important to allow several programs to share the available modems with the kernel networking. A new flexible configuration file allows setting of many new options. There will be section devoted to this configuration file which will describe the options in detail. The timeout mechanisms have been expanded. A "call wait" timeout is supported for the maximum waiting period between a call request and the completion of the call. Once a call has failed, a "failed call" timeout indicates the time to wait before initiating a new call. The activity timeout is represented by one of 3 timeouts including "inactivity", "tcp close", and "non tcp", representing the conditions when TCP connections are active, no TCP connections are active, and non TCP traffic is active. The concept of a modem has been expanded to include a modem rotary. A rotary is a group of modems that are used in a round robin fashion. With a bank of modems and phone lines, there are basically two ways to pick which modem to use next: "first available" and "next available". The "next available" option corresponds to a "rotary", a round robin selection, and can be used in order to be more tolerant of a single modem or phone failure. Given modems 1 to N, if modem number 1 fails, the "first available" selection will always fail and the "next available" selection will fail 1 out of N times. SunOS allows use of a single modem for both dial in and dial out through the use of two minor device numbers for each port. This facility has been completely integrated into this software so that a single port can be easily used for both incoming and outgoing calls. A new program "dplogin" is included which shares a number of functions with "dpd". "dplogin" is used as a login shell for incoming calls and uses the same configuration file as "dpd". It handles locking and logging in a compatible way. A call log file is now generated for both incoming and outgoing calls. Each line of the file corresponds to a successful call and includes the following information: remote site name, tty device, date and time of initiation of connection, total connect time, initiating program (dpd or dplogin), protocol and port of initiating request (like tcp/smtp), and for both input and output, a report is given of number of packets, bytes, and errors. The protocol and port information is only available for outgoing calls. This information can be very useful for analyzing call patterns and minimizing costs. An auxiliary program facility is provided. If so configured, whenever a modem connection is made, an auxiliary program can be run. This program could, for instance, check queues for outgoing traffic and make use of the the connection to transfer mail, print jobs, or other similar queued files. This could be easily tuned to be site specific to reduce the number of calls made by taking advantage of connections when they happen. 3.5 "sys" directory The sys directory includes the kernel modules, including the following: 3.5.1 ppp_async.c The "pppasync" streams module, which is used in conjunction with both the original "pppif" module and the new "dpif" module. 3.5.2 dp_if.c The new version of ppp_if.c which has been heavily modified to support the dialup on demand mode of operation. dp_if.c is based originally on the ppp_if.c module from Clarkson University and Brad Clements. It has been expanded in several ways. The connection status of each interface is now handled and a number of timeouts are implemented. The timeouts include the following: callwait: time to wait for a call to complete failedcall: time to wait before trying another call inactivity: disconnect after no packets in A seconds. tcp_close: disconnect C seconds after last TCP connection is closed and no packets. non_tcp: disconnect U seconds after last non-TCP packet given no activity and no TCP connections. The timeouts can be set from the dp configuration file. In addition, a completely new module keeps track of TCP connections in progress and will notice when all connections close and the line can be disconnected using one of the "fast timeouts" (tcp_close or non_tcp). The Van Jacobson header compression code is included and works well with this package. Included within dp_if.c is a driver for the "pppdial" streams device that allows the kernel to request the initiation of calls from the "dpd" program. 3.6 "dptrace" directory Dptrace is a simple program that prints the request trace file. As each dialup request arrives through /dev/dp0, the dpd program writes the current time and the current request to the file "${DPLOG_DIR}/req.trace". This program reads that file and formats the requests into a readable format. The program can be helpful in debugging and tuning the network. 3.7 "modem" directory This directory contains a program to set modem options on Hayes compatible modems. The "setmodem" command can be invoked as: setmodem [-v] scriptfile device [baud] Scriptfile contains a number of AT commands that will be fed to the modem. The setmodem program knows enough to expect OK returns from the modem and waits until the OK to proceed to the next AT command. Scripts for the telebit T1600, T3000, and WorldBlazer modems are provided and have been tested. You can modify these further to suit your configuration. In addition, there is a shell script "initmodem.sh" which can be invoked as: initmodem scriptfile outdev indev [baud] The scriptfile is the same as in setmodem, and the outdev corresponds to the device in setmodem, but the indev is the login side of the same device that is given in /etc/ttytab. This script first edits /etc/ttytab to turn the login off for that port. This allows everything to work correctly with the softcarrier options, etc. The program resets the port before completion and generally is the preferred way to handle the initialization of devices. 3.8 "aux" directory The aux directory contains the sources for auxiliary programs that can be run when connections are established. If so configured in the "${DP_CONFDIR}/conf" file, whenever a modem connection is made, an auxiliary program can be run. Currently, the only program provided is a program called ckmailq. This looks in the mail spool directory for outgoing mail that is not currently being processed. If such mail exists, it starts up sendmail with the proper options. Other similar programs could be written for other queued traffic such as print jobs or uucp requests. This can be used to "poll" for SMTP mail when a remote site can't initiate calls on it's own. 3.9 "access" directory The access directory contains several example files for controlling remote access and timeouts. These are installed in "${DPACCESS_DIR}. 3.10 "script" directory The script directory contains several dialing and login scripts. These can be used as examples for your particular modems, etc. These files are installed in ${DPSCRIPT_DIR}. 3.11 "cron" directory The cron directory contains two shell programs (daily and monthly) that can be run via crontab in order to keep the ${DPLOG_DIR} directory from getting too large. The file dp.crontab contains the two entries that need to be manually entered into root's crontab in order for these programs to be run via cron. 4. Building & Installation In this release there are two ways to install dp. One is to use the loadable module support in the current version, but this has known problems with unloading (which may not be a problem in most situations). The other method is to install the dp drivers directly into the kernel with a kernel rebuild. This option will go away with Solaris 2.0, but works quite will under Solaris 1.0, and has no known problems. In the end, you will need to use the method that is most appropriate in your situation. Below, both methods are covered in detail. In either case, the rest of dp must be built and installed in the way given below. 4.1 Loadable Module Version Install 4.1.1 Building & Installing In most cases, for SunOS 4.1.x at least, dp should build "out of the box", and you should just do this: * According to local policy, create a new group called "ppp", we suggest an id of 600. This would normally be done by adding an entry to "/etc/groups" or adding an entry on the NIS master if you use that. For more details see section XXX. * Unpack the distribution, which creates a directory called dp-2.3/ * cd to dp-2.3/ * type "make" and make sure there were no errors, then * Become "root", and type "make install", which will create all the necessary directories and copy the files required across setting the correct ownerships and permissions. 4.1.2 Using Loadable DP For general configuration details you should proceed to section XXX, but in addition you have to set up your system to load the modules at some stage, usually at boot time. To run from "/etc/rc.local" you should add the following lines to the file: if [ -f ${DPMODULE_DIR}/startdp ]; then ${DPMODULE_DIR}/startdp echo "started dialup PPP" fi Be sure to modify the ${DPMODULE_DIR} to reflect your system installation. 4.2 In-Kernel Version Install For whatever reason, it may be necessary to install the dp modules in the kernel. The main reason is that the loadable modules are not fully supported at this release, or local policy may curtail the use of them in future release. This section goes through manual installation procedure. The dp network interface must be installed in the kernel. To install this software, we must reconfigure, rebuild, and reboot with a new kernel (/vmunix). 4.2.1 /usr/sys/conf.common/files.cmn So that the "config" program knows where to find the drivers, the following lines must be added to the end of the file "/usr/sys/conf.common/files.cmn": os/dp_if.c optional dp os/ppp_async.c optional dp 4.2.2 /usr/sys/sun/conf.c This file will contain the description of the pppdial streams device. This device allows communication between the kernel network interface and a user program "dpd" which makes calls and establishes connections. Before the definition of the cdevsw array, a number of #defines are set up for each device. After the last such setup and before the cdevsw array, place the following lines: #include "dp.h" /* Dialup PPP */ #if NDP > 0 extern struct streamtab ppp_dialinfo; #define dptab &ppp_dialinfo #else #define dptab 0 #endif The cdevsw array contains an entry for each supported device. The supported devices and the number of such devices varies somewhat from release to release. In SunOS4.1.1, the last supported device is 103, as indicated in a comment to the right of the device definition. Assuming no other local devices, then, the Dialup PPP device would be device number 104 and defined as follows: { /* Dialup PPP */ nodev, nodev, nodev, nodev, /*104*/ nodev, nodev, nodev, 0, dptab, 0, }, The exact position in the array does not really matter as long as you use the correct number when you create the device. In this case, 104 is the major number of the device and will be used later when the device is created. 4.2.3 /usr/sys/sun/str_conf.c This file defines the 3 streams modules involved. Dialup PPP uses "dpif", "pppdial", and "pppasync". Near the beginning of the file, there are a number of #include directives. After the last one, place the following line: #include "dp.h" Then, there are a number of extern definitions based on #if directives. After the last one, place the following lines: #if NDP > 0 extern struct streamtab dp_ifinfo; extern struct streamtab ppp_dialinfo; extern struct streamtab ppp_asyncinfo; #endif Then, there is a fmodsw array defined. This array defines all the streams modules in the system. Near the end of this array, before the loadable modules are defined (VDDRV), put the following lines: #if NDP > 0 { "dpif", &dp_ifinfo }, { "pppdial", &ppp_dialinfo }, { "pppasync", &ppp_asyncinfo }, #endif 4.2.4 /usr/sys/sun4c/conf/CONFIG_NAME Each kernel is built from a configuration file with some name. By default, when SunOS boots, it places that name in a comment in the file /etc/motd. You can tell which configuration was used to build the current system by looking at that file. It is probably best to copy that configuration file to a new file, perhaps with "_DP" appended to the name. For purposes of discussion, we will call the new configuration "SYS_DP". Then edit the new configuration file and add the following lines: # # Point to Point Protocol (PPP) devices # pseudo-device dp init dp_attach If you want more than one interface (like for a central hub), just put the number after "dp". For instance, for 8 interfaces, use the line: pseudo-device dp8 init dp_attach 4.2.5 New Source Files From the "sys" directory in the distribution, copy the following files to the "/usr/sys/os" directory: dp_if.c ppp_async.c From the "h" directory in the distribution, copy the following files to the "/usr/sys/sys" directory". dp_str.h if_ppp.h slip_var.h slcompress.h 4.2.6 Configuring and Compiling In the directory "/usr/sys/sun4c/conf", run the command: /usr/etc/config SYS_DP Use the name of the file you edited in the previous step in place of "SYS_DP". Then, change to the directory "../SYS_DP", and run make. You should get a new kernel "vmunix". In order to install the new kernel on your system, you should save a copy of the old kernel with "cp /vmunix /vmunix.old", then "cp /usr/sys/sun4c/SYS_DP/vmunix /vmunix". Then, reboot using the "shutdown" or "reboot" command. 4.2.7 Creating Devices Only one new device needs created in the /dev directory. This is the "pppdial" streams device that is used to pass dial requests from the kernel "dpif" module to the "dpd" program. It should be created with a major number that is dependent on the exact contents of the "/usr/sys/sun/conf.c" file. For this example, we will assume the major number is 104. These are the commands you would use: # /usr/etc/mknod /dev/dp0 c 104 0 # /usr/etc/chown root.staff /dev/dp0 chmod 600 /dev/dp0 4.3 System Files A number of system files need entries added according to your own setup. These files will be discussed here. 4.3.1 /etc/passwd & /etc/group This procedure may vary slightly depending on the use of NIS or shadow password files. But, basically you will be defining users and groups much like you would for a new system user. Feel free to adapt this procedure to your specific arrangement. You should have defined a new group called "ppp" earlier in the installation if you used the loadable module support, otherwise assign a suitable id. In our case, we used the group id 600. For each remote site that will be calling in, you need to create a login. We have used the convention that PPP logins all start with the letter 'P'. This has made it easy to identify it as a "special" sort of login when looking at the output of "who" or "finger". Assume that we have 2 remote sites: "rem1" and "rem2". We have selected available user id's 601 and 602, respectively. Additionally, we have selected group id 600 for group "ppp". The "/etc/passwd" file entries would take the following form: Prem1:*:601:600:PPP Remote 1:/var/adm/dp:/usr/dp/bin/dplogin Prem2:*:602:600:PPP Remote 2:/var/adm/dp:/usr/dp/bin/dplogin The entry in the "/etc/group" file would look like this: ppp:*:600:Prem1,Prem2 After creating these entries, we would use the command "passwd Prem1" to set the password for the "Prem1" account, and similarly for "Prem2". 4.3.2 /etc/rc.boot At some point in the boot process, you must arrange to run ifconfig on all your "dp" interfaces. Sun has arranged code in /etc/rc.boot to do all the ifconfig's automatically. If you do not use the dynamic loading, you can use this code, but it needs minor modification to make it work. You can simply add the ifconfig lines directly in one of the rc files (before starting dpd), or you can modify /etc/rc.boot and use the Sun scheme. Here are the modifications necessary to /etc/rc.boot. The line: hostname="`shcat /etc/hostname.??0 2>/dev/null`" needs changed to: hostname="`shcat /etc/hostname.?e0 2>/dev/null`" Later, this file messes with IFS and then looks for files of the form "/etc/hostname.*". The lines: IFS="$IFS." set `echo /etc/hostname\.*` need changed to: SIFS=$IFS IFS="$IFS." set `echo /etc/hostname\.*` IFS=$SIFS The line: ifconfig $1 "`shcat /etc/hostname\.$1`" netmask + -trailers up needs changed to: ifconfig $1 `shcat /etc/hostname\.$1` netmask + -trailers up In the file "/etc/hostname.dp0", you need to place the source and destination addresses for the first PPP link. The source address is the address on the local machine, and the destination address is the address on the remote machine. These addresses can be hostnames from the hosts database or internet numeric dot notation. Create one of these files for each PPP link. 4.3.2 /etc/rc.local After the "ifconfig" commands are run at boot time, before using the PPP interfaces for anything else, you must start the Dialup PPP Daemon (PPP). In /etc/rc.local, there is a line similar to: ifconfig -a netmask + broadcast + > /dev/null Right after that line is a good place to start dpd. The lines to add look like this: # # Start Dialup PPP Daemon. # if [ -f /etc/dp.start ]; then /etc/dp.start echo 'starting Dialup PPP Daemon.' fi 4.3.4 /etc/hosts In short, you need an entry in "/etc/hosts" for each "dp" interface. Each PPP link is a network in it's own right. So, it to be assigned a unique internet IP number for each end. For broadcast networks, a network address is assigned for each physical network. Host numbers are chosen for each host on the network. For an example class C addresses 199.10.11.14 and 199.10.11.52 are both on the same IP network (199.10.11). These addresses represent hosts 14 and 52 on that network. IP routers know how to get to the 199.12.13 network and pass packets on to the appropriate gateway. Once the packets get to that network, they are then routed to host 14, 52, or whatever. In contrast, the number of hosts on a Point to Point network is always 2. So, in IP routing, we never actually use a route to the network. We just use a route to each individual address (both ends). So, if we are administering several Point to Point networks, we can use a single IP network, and assign pairs of addresses. For instance, assume we have a class C network 199.10.20 assigned for PPP links. Our first link could have the addresses 199.10.20.1 and 199.10.20.101. Our second link could have the addresses 199.10.20.2 and 199.10.20.102. We need two addresses for each link since we need to assign an address to each end. Using addresses differing by 100 for both ends of the link has proven to be a convenient convention for us. It helps us to keep track of things when dealing with a large central hub. So, let's say we have a hub machine called "hub", with 2 PPP links, "dp0", and "dp1" serving the machines "rem1" and "rem2". Each of these remote machines have a single PPP interface "dp0". Using the addresses from the previous examples, we would have /etc/hosts entries as follows: 199.10.11.14 hub hub-le0 199.10.20.101 hub hub-dp0 199.10.20.102 hub hub-dp1 199.10.20.1 rem1 rem1-dp0 199.10.20.2 rem2 rem2-dp0 These are just guidelines and address assignment can be done in a different ways based on local conventions and local politics. In addition to the hosts file, many sites will also be using the DNS (Domain Name System). The DNS files need updated to reflect the new network addresses in a similar way. In addition, routing can be quite different based on the protocols involved. For further discussion about DNS and routing, see the later sections detailing a sample configuration. 5. Configuration 5.1. "/etc/dp.conf" file Earlier versions of Dialup PPP placed files in very specific places. dp-2.3 allows flexible placement of files. The only really fixed file is /etc/dp.conf. It basically contains a list of pathnames for standard things. It looks like this: # # Config file for Dialup PPP. # # This file specifies the paths where all the related PPP files and # programs are located. # DPCONF_DIR=/etc/dp # System Specific Files DPLOG_DIR=/var/adm/dp # Log and Trace Files DP_DIR=/usr/dp # Common Files for All Systems DPBIN_DIR=${DP_DIR}/bin # Programs DPSCRIPT_DIR=${DP_DIR}/script # Standard Dialing Scripts DPACCESS_DIR=${DP_DIR}/access # Standard Access Files DPAUX_DIR=${DP_DIR}/aux # Auxilliary Programs DPMODEM_DIR=${DP_DIR}/modem # Modem Support Programs DPMODULE_DIR=${DP_DIR}/modules # Kernel Modules The DPCONF_DIR typically contains files that are specific to a given system. The "${DPCONF_DIR}/conf" file contains the bulk of the interface configuration. In addition, script and access files specific to a single system can be placed in this directory. The DPLOG_DIR contains log files and files that get written frequently. The other directories should be relatively static from one machine to the next. The default configuration file groups them all under ${DP_DIR}. This can be changed to suit local needs. 5.1 "${DPCONF_DIR}/conf" file When, the programs "dpd" and "dplogin" are started, they read a configuration file "${DPCONF_DIR}/conf". This file has a definition for each interface, each modem, and optionally a number of modem rotaries. An definition of begins with a line beginning in the first column. Continuation lines must begin with white space (SPACE or TAB characters). Comments can be placed anywhere in a line and must begin with #. Strings can be delimited by double quote characters (""), if necessary. For a given definition, each variable is given a value with a the variable name, an equal sign, and the value. For instance, the first entry in the definition for the dp0 interface is: IF=dp0 This section defines all the possible options, their possible values, and gives some examples to show how they might be used. 5.1.1 Interfaces Each interface corresponds to a logical network connection to a single remote site. Provisions are made in the interface definition to specify how calls should be made and received in order to handle traffic on that interface. 5.1.1.1 IF The IF variable must be the first entry in the interface definition. It's value is the name of the network interface (e.g. IF=dp0). 5.1.1.2 SYS The SYS variable can be optionally set to indicate a system name to be used when making log entries. If the SYS variable is not explicitly set, it is defaulted to be the internet name of the remote site (as returned by gethostbyaddr()), or if that fails, the internet address of the remote site in dot notation. 5.1.1.3 MODEMS The MODEMS variable specifies the modems or modem rotaries that should be used to make calls for this interface. At least one modem or modem rotary must be specified. If more than one modem or modem rotary is specified, when a call request is made, each entry in the list is tried in turn until an available modem is found. The names used in this list must correspond to a MODEM or ROTARY definition as specified in the configuration file. 5.1.1.4 PHONE The PHONE variable specifies the phone number that will be passed to the DIAL_SCRIPT as defined by the modem in use on a particular call. 5.1.1.5 LOGIN_SCRIPT The LOGIN_SCRIPT variable specifies an expect script that will be used to log into the remote system for the purposes of establishing a PPP connection. These scripts are found, by default, in ${DPSCRIPT_DIR} and will be described in detail later. Scripts specific to a single system can also be placed in ${DPCONF_DIR}. 5.1.1.6 LOGIN_ARGS The LOGIN_ARGS variable is a comma separated list of arguments to the expect script as defined by the value of LOGIN_SCRIPT. This is typically the login and password on the remote machine. 5.1.1.7 LOGIN The LOGIN variable has practically nothing to do with the LOGIN_SCRIPT and LOGIN_ARGS variables, both of which deal with outgoing calls. The LOGIN variable, instead, is set to allow a particular login id to be used to call in to establish a PPP connection. When dplogin is called, it knows what account was used to log into the system. It searchs the configuration file for an interface where the LOGIN variable is set to that same account. 5.1.1.8 TRACE The TRACE variable can be used to specify a trace file for the calling script. The trace files are written in ${DPTRACE_DIR}. If there is a problem with establishing a particular connection, this variable can be set to see what characters are being transfered when the DIAL_SCRIPT and LOGIN_SCRIPT are both run. 5.1.1.9 ACCESS An ACCESS file can be specified. This file defines a number of additional variables and can be used to limit the conditions for which calls will be made. This file is located, by default, in the ${DPACCESS_DIR} directory. Access files local to a single system can be placed in the ${DPCONF_DIR}. This file will be described in detail in the next section. 5.1.1.10 PPP_ARGS When the PPP program "${DPBIN_DIR}/dp" is started by dpd or dplogin, you can specify additional arguments to be put in the argument list. For instance, if you are using dp.2.3 to talk to a dp.2.0 installation, the default header compression negotiation has changed with the new patch level of PPP. So, in the 2.3 configuration file, you can put the line: PPP_ARGS=vjmode,old This will talk to a patchlevel 4 PPP correctly and the option negotiation will function properly. 5.1.1.11 AUX The AUX variable specifies an auxiliary program that will be run after a PPP link is established for a particular interface. The default location for these programs is ${DPAUX_DIR}. An example program is provided that checks the sendmail queue for queued messages. This could be run to make sure mail messages are sent out whenever the link is established for any reason. 5.1.1.12 AUX_ARGS Arguments may be provided to AUX program by specifying them here as a comma separated list of arguments, much like the PPP_ARGS variable. The last argument provided to the AUX script is always the system name from the SYS variable. 5.1.1.13 LOG_LEVEL The Log Level can be set when dpd is started. The LOG_LEVEL variable overides the current log level for calls made to this system. In addition, dplogin will set the same LOG_LEVEL for incoming calls. 5.1.1.14 ASYNC_MAP The PPP program can be setup to avoid using certain control characters in the case of links that aren't totally transparent. This takes the form of a 8 digit hexadecimal string representing a 32 bit number. The lowest to highest order bits of the number correspond to the ASCII character represented by 0 through 31. If the bit is set, that character will not be transmitted on the line, but will instead be replaced by a special escape sequence. By default, the ASYNC_MAP is set to 0, which means pass all characters since we have a totally transparent link. This variable applies to all calls made to this system independent of which modem was used. 5.1.2 Modems A modem entry is required for each serial device that can be used to establish a connection to a remote system. 5.1.2.1 MODEM The MODEM variable must be the first entry in the modem definition. It's value is an arbitrary (hopefully descriptive) name. This same name is used in the interface definition as a value for the MODEMS variable. 5.1.2.2 DEV The DEV variable is set to the physical serial device name path name. If the entry does not begin with a "/", then it is assumed that the device appears in the "/dev" directory. Sun has a scheme for using the same line for dial out and dial in. For most configurations, you should use the name of the dial out device. This is the one with the 0x80 bit set in the minor number. If necessary, you can make the dialout device for a given login port. As an example, assume we are using "ttya" and we want to make a dialout device "cua0". Here are some example commands run as root to make the device. # ls -lg /dev/ttya crw--w--w- 1 root wheel 12, 0 May 21 12:30 /dev/ttya # /etc/mknod /dev/cua0 c 12 128 # chmod 660 /dev/cua0 # /etc/chown uucp.uucp /dev/cua0 # ls -lg /dev/ttya /dev/cua0 crw--w--w- 1 root wheel 12, 0 May 21 12:30 /dev/ttya crw-rw---- 1 uucp uucp 12, 128 May 21 12:30 /dev/cua0 Then, you would put "DEV=cua0" in your modem definitions to use this device. 5.1.2.3 DIAL_SCRIPT The DIAL_SCRIPT variable is the name of a script file. The directories ${DPCONF_DIR} and ${DPSCRIPT_DIR} are searched for these files. By convention, common scripts are placed in ${DPSCRIPT_DIR} while scripts specific to single systems are placed in ${DPCONF_DIR}. This script will be used to interact with the modem and make the call. The phone number is passed as the first and only argument to the script. The next section describes modem rotaries. If all the modems in a rotary use the same DIAL_SCRIPT, it is not necessary to set each one individually. The DIAL_SCRIPT variable is set from the ROTARTY definition. 5.1.2.4 BAUD The BAUD variable is the baud rate to use for outgoing calls on this modem. The next section describes modem rotaries. If all the modems in a rotary use the same baud rate, it is not necessary to set each one individually. The BAUD variable is set from the ROTARTY definition. 5.1.2.5 DIAL_CHARMAP This variable is set in order to map characters embedded in phone numbers to the appropriate modem control character. For instance, it may be a common practice to include a '=' in phone numbers when you have to wait for a secondary dial tone and a '-' when you just have to pause for a second. For Telebit modems, then the mapping would be performed with: DIAL_CHARMAP==W-, which means wait for dial tone is 'W', and a short pause is ','. This allows modems of different brands to be used without undue difficulty. 5.1.2.6 ASYNC_MAP The PPP program can be setup to avoid using certain control characters in the case of links that aren't totally transparent. This takes the form of a 8 digit hexadecimal string representing a 32 bit number. The lowest to highest order bits of the number correspond to the ASCII character represented by 0 through 31. If the bit is set, that character will not be transmitted on the line, but will instead be replaced by a special escape sequence. By default, the ASYNC_MAP is set to 0, which means pass all characters since we have a totally transparent link. This variable applies to all calls made with this modem. 5.1.3 Modem Rotaries If you are administering a central hub machine with several modems, you may wish to define a modem rotary. When defining the interfaces, you can set the modem variable to a list of modems (or rotaries). Each one will be tried in turn until an available modem if found. For a large number of modems, this is not very tolerant to hardware failures. If the first modem in the list is broken, calls will always fail. This approach is sometimes called using the "first available" modem. An alternative approach is to define modem rotaries. A rotary is best described as a "next available" approach. The software keeps track of the last modem used, and always starts with the next modem in the list. When the end of the list is reached, the first modem becomes the next modem. This reduces overhead of finding a free modem and insures that a bad modem will not totally shut down communications. 5.1.3.1 ROTARY The ROTARY variable must be the first entry in the modem definition. It's value is an arbitrary (hopefully descriptive) name. This same name is used in the interface definition as a value for the MODEMS variable. Modems and rotaries can both be listed in the MODEMS variable equally well. 5.1.3.2 MODEMS The MODEMS variable is set to a comma separated list of one or more modems. The entries in the list are the names of the modems as defined by their MODEM variable. All entries in this list must be modems. Other rotaries cannot be used here. 5.1.3.3 DIAL_SCRIPT The DIAL_SCRIPT variable is the name of a script file. The directories ${DPCONF_DIR} and ${DPSCRIPT_DIR} are searched for these files. By convention, common scripts are placed in ${DPSCRIPT_DIR} while scripts specific to single systems are placed in ${DPCONF_DIR}. This script will be used to interact with the modem and make the call. The phone number is passed as the first and only argument to the script. This entry will be used if the MODEM definition does not define a DIAL_SCRIPT itself. This is useful when a pool of modems are all the same type and the DIAL_SCRIPT is the same for all of them. 5.1.3.4 BAUD The BAUD variable is the baud rate to use for outgoing calls on any modem in this rotary. This entry will be used if the MODEM definition does not define a BAUD itself. This is useful when a pool of modems are all the same type and the baudrate is the same for all of them. 5.1.3.5 DIAL_CHARMAP This variable is set in order to map characters embedded in phone numbers to the appropriate modem control character. For instance, it may be a common practice to include a '=' in phone numbers when you have to wait for a secondary dial tone and a '-' when you just have to pause for a second. For Telebit modems, then the mapping would be performed with: DIAL_CHARMAP==W-, which means wait for dial tone is 'W', and a short pause is ','. If all the modems in a rotary are of the same brand, it is convenient to set this variable in the rotary definition rather than setting it in each modem definition. 5.1.3.6 ASYNC_MAP The PPP program can be setup to avoid using certain control characters in the case of links that aren't totally transparent. This takes the form of a 8 digit hexadecimal string representing a 32 bit number. The lowest to highest order bits of the number correspond to the ASCII character represented by 0 through 31. If the bit is set, that character will not be transmitted on the line, but will instead be replaced by a special escape sequence. By default, the ASYNC_MAP is set to 0, which means pass all characters since we have a totally transparent link. This variable applies to all calls made with any modem in this rotary. If all the modems in a rotary are of the same brand, it is convenient to set this variable in the rotary definition rather than setting it in each modem definition. 5.2 Access Files An access file can be defined to describe the conditions when a call is permitted and to set the timeouts appropriately. For instance, if you have some sites that are long distance toll calls, and some that are local calls, you may wish to have shorter timeouts on the toll calls than on the locals. The format of the access came from the BBN DialupIP software. It has been expanded in several ways, but it still looks pretty similar. Aside from several small changes in the existing options, a series of timeout specifications have been added. 5.2.1 Timeouts There are eight timeouts which can be specified, three that can be set separately for incoming and outgoing calls, and 2 more that only make sense for outgoing calls. Here is a sample section from a access file showing all 8 timeouts: # # Connection Timeouts # failedcall 25 # time to mark network as down after failed call callwait 50 # time to allow for call to go through # # Activity Timeouts # dial:inactivity 180 # time to let the connection sit idle dial:last_close 6 # fast timeout after last TCP close dial:non_tcp 10 # fast timeout for non-TCP traffic answer:inactivity 600 # time to let the connection sit idle answer:last_close 180 # fast timeout after last TCP close answer:non_tcp 180 # fast timeout for non-TCP traffic Since we are not dialing 800 numbers, we are paying for calls made. In that case, we set short timers so that disconnections are prompt. For incoming calls, we set some limits just to keep the modem pool from being tied up. 5.2.1.1 Callwait When the kernel "dpif" module requests a call be placed by "dpd", the kernel starts the call wait timer. If no status has been reported from "dpd" within "Callwait" seconds, it is equivalent to receiving a "FAILURE" status from "dpd". 5.2.1.2 Failedcall After a FAILURE status or after the expiration of the Callwait timer, the interface is marked with the FAILEDCALL status. With that status set, no calls will be attempted. After "Failedcall" seconds, the interface status is marked as DISCON, and call attempts will again be made. 5.2.1.3 Inactivity If no packets have been sent or received through a PPP interface within "Inactivity" seconds, PPP is terminated and the interface is marked as DISCON. 5.2.1.4 Tcp_close TCP packets contain information about connections starting and ending. A count of active connections is maintained for each interface. When this count goes to zero, if no packets have been sent or received within "Tcp_close" seconds, PPP is terminated and the interface is marked as DISCON. 5.2.1.5 Non_tcp When the active TCP connection count goes to zero, and non-TCP packets are being transmitted, if no packets have been sent or received within "Tcp_close" seconds, PPP is terminated and the interface is marked as DISCON. 5.2.2 Protocols We can limit the calls made by the protocol. Here is a sample access file entry that would only allow tcp, udp, and icmp packets: protocols tcp udp icmp The keyword "goodprotocols" can be used in place of "protocols". In addition, the keyword "badprotocols" can be used to disallow calls based on packets certain protocols. Any protocol that is in the "/etc/protocols" file is a valid entry on this line. Please note that this only controls the initiation of a call request. Once a call succeeds, other protocols can be transmitted. 5.2.3 Times By default, calls can be placed at any time. If you wish to limit calls during certain hours of certain days, you can place entries in the access files containing the day and the hours when calls are should not be permitted. The allowable days are: sun sunday mon monday tue tuesday wed wednesday thu thursday fri friday sat saturday weekdays weekends For instance, if calls should only be allowed during "business" hours of monday through friday (8-5), with no calls in the evening or weekends, you would use the following entries: weekdays 0 1 2 3 4 5 6 7 17 18 19 20 21 22 23 24 weekends 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 If a day is not mentioned either explicitly or via the weekday/weekend keyword, then calls can be placed all day. To allow calls only during times with lower rates, one might want to turn off calls during the 8-5 business day. This would be done with the following line: weekdays 8 9 10 11 12 13 14 15 16 Calls would then be placed anytime before 8AM and after 5PM on weekdays and any time on weekends. 5.2.4 Hosts/Networks To limit calls when certain hosts are involved, you can use further keywords. In order to limit calls to packets which are destined to a list of specific hosts, you would use the "allowto" (or equivalently "gooddstaddresses") keyword. If the access file has a line of this form, a call will fail for packets having destination addresses not in this list. So, if we wish calls to be placed for only one hosts on the 192.100.10.0 network and the goodhost.com host, a line of the following form would be used: allowto 192.100.10.0 goodhost.com In order to limit where a packet may come from, you can use the "disallowfrom" (or equivalently "badsrcaddresses") keyword. If a call request is made for a packet coming from an address in this list, then the call fails. An example would be disallowfrom badhost.edu The addresses given in these lists can be the name of a network, the name of a host, or equivalently an internet host or network address in dot notation. 5.3 Script Files The script mechanism is used by the dpd program to interact with modems and systems to make calls and log in to remote computers. They provide a full send-expect style facility, with many extensions to allow for timeouts, alternative choices and others. This is a direct extension of the DialupIP 2.0 script file mechanism with the following additions: - Two separate scripts are required for dialing and for login. - Timeouts can be 0 to indicate matches of previously received data (via a mark/replay command pair). - "recv" commands can match more than one alternative string Script files contain a sequence of lines, each with a command and zero or more arguments. Blank lines and lines beginning with # are ignored. Strings must be quoted with double quotes (") if they contain white space. Standard C escape sequences are valid (\b, \f, \n, \r, \t, or \000 where 000 is any octal number). Several example script files are provided in the distribution for dialing several different Telebit modems directly into a remote system as follows: t1600-dial Dials the given number on a Telebit T1600 modem. t3000-dial Dials the given number on a Telebit T3000 modem. wb-dial Dials the given number on a Telebit WorldBlazer modem. ppp-login Logs into a remote system directly. The first argument is a login, and the second argument is the password. This assumes the login shell on the remote system is "dplogin", and performs simple synchronization with that program. You may note that the t3000 and Worlblazer scripts are the same since we use V.32bis in both cases. For PEP usage, the WorldBlazer script will need modified to handle additional CONNECT messages. 5.3.1 abort The "abort" command terminates the script with a failure code returned. Reading the script past the end of file is equivalent to the "abort" command. 5.3.2 go The "go" command indicates success. For a dial script, success means that the call went through using the specific modem. For a login script, success means that PPP is started on the remote computer. 5.3.3 log "text" This writes the given string to the log file (${DPLOG_DIR}/dp.log). 5.3.4 mark As incoming bytes are received, they are saved in a buffer for possible later use by "replay". The mark command indicates the beginning of where to start saving characters. 5.3.5 replay Characters in the incoming buffer are replayed as if they are being received again. This replay starts at the most recent mark command. 5.3.6 recv "text" [ "text" ... ] timeout The recv command is used to examine the incoming characters (which can be actual new characters, or older ones after a replay command. The command succeeds when a substring of the incoming characters matches one of the "text" patterns given. If the match has not succeeded in "timeout" seconds, the "recv" command returns failure. However, if the "recv" command is in a "select block", control is passed to the next alternative. 5.3.7 use script [ "parameter" ... ] The use command executes another script file and returns success or failure depending on the execution of the named script. 5.3.8 xmit "text" This sends the indicated text to the remote system. A \x in the string will delay 1 second, and a \# will send a break. Also, the string $1 will be replaced by the first argument to the script, and so on. The arguments are given in the dp-conf file or as arguments the the "use" command. 5.3.9 Select Blocks Select blocks allow you to specify alternatives on failure of specific "recv" commands. The format is as follows: { alternate commands... alternate commands... } The "{", "}", and "alternate" keywords are commands and must be on separate lines. If a "recv" command fails, then control is passed to the next alternate. If all alternatives fail, then the select block returns a failure, and is equivalent to an "abort". 6. Routing There are two ways, in general, that you will connect systems together with dp. The first is a single machine (typically at home) to a network of systems (the office network or maybe the Internet) and second to connect two networks (two sites for example, or an office network to the Internet). In either case, the networking software has to know how to get to the "other" systems. This is done in the kernel by routing tables. There is at least one route to each interface, but the administrator (you) can add more. 6.1 Static Routing Where there is a single machine and a remote network or two reasonably stable networks which are under your administrative control, then the simplest way of setting things up is to use static routes. Again, in the Unix way there is always more than one way of doing things, and this is true for installing route into the kernel. 6.1.1 "route" The most direct way to install a new route is the use the route(8) command. "route" will allow you, as superuser, to add and delete routes in the kernel. There are three (really two) types of route: * Route to a host. This type of route effectively says: you can get to this host via this interface. * Route to a network. This type says there is a network over there, past that interface on the left :-) * The default route. The is a special route that is used as a catch all. It is most useful for a single host (home) connecting to everything else and tells the networking software to route everything down a single line if the is no other explicit route for it. As an example, let's say that a home system is connected to a work system via a PPP link. "home.com" has the PPP interface of 192.220.10.1 "work.com" has the PPP interface 192.220.10.2 and the ethernet interface 192.220.11.18. In order to another machine on the work ethernet to get to the home system, it would need the command /usr/etc/route add 192.220.10.1 192.220.11.18 1 In order for the home system to reach other hosts on the work ethernet, it would need the command: /usr/etc/route add 192.220.11.0 192.220.10.2 1 Assume now that the ethernet is connected to other networks or the Internet. Then, the best command for home.com would be: /usr/etc/route add default 192.220.10.2 1 This would route all remote packets through the PPP interface. 6.1.2 "/etc/gateways" The other method is to create a file called "/etc/gateways" that lists static route available at boot time (more correctly when the routing daemon is started). This file is read when "in.routed" is started in "/etc/rc.local". For further information, see the routed(8c) manual page. 6.2 Dynamic Routing In the case where two networks are connected, and these may have further connections added to them or taken away, then there must be a way for the routing information to be updated at regular intervals so that packets can get to their intended destinations. 6.2.1 Routed Routed(8c) has been used extensively for adapting routes to changing network connectivity. It will work in this case of PPP links. Routed works by sending RIP packets (Routing Information Protocol) on every interface every 30 seconds. Clearly, if we wish to disconnect the phone when our interface is not in use, this will cause problems. For this reason, routed is probably not the best choice for routing on hosts with dialup PPP interfaces, unless the intent is to keep the phones connected all the time. 6.2.1 Gated Gated is a program that knows about routing via several protocols. It can handle RIP (routed) packets, as well as other protocols such as EGP (External Gateway Protocol) and GGP (Gateway to Gateway Protocol). It also can be used to consider certain routes as "static" and to be always available. These routes can then be advertised using any of the available routing protocols, including RIP. If you have RIP based routing, then gated can be easily set up on your hub machine up to use static routing for the PPP links and use RIP for the other (ethernet?) networks. Here is an example gated configuration file for our campus hub that talks to 6 remote systems, each with a local ethernet at the other end: # # Config file gated on phoenix.acn.purdue.edu # traceoptions internal external route rip update ; #tracefile "/tmp/gated.trace" ; interface all passive ; # don't time out my interfaces! # # Do rip except on the PPP interfaces # rip supplier { interface dp0 noripout noripin ; interface dp1 noripout noripin ; interface dp2 noripout noripin ; interface dp3 noripout noripin ; interface dp4 noripout noripin ; interface dp5 noripout noripin ; } ; # # Set up static routes to remote ethernets at the end of PPP links # We are advertising ourself as a gateway to the subnetwork assigned # to the PPP links. For each remote ethernet, the remote end of a PPP # link is being advertised as a gateway. # static { 128.46.177.0 gateway 128.46.157.167 ; # PPP Links 128.46.34.0 gateway 128.46.177.34 ; # Remote ethernet 128.46.181.0 gateway 128.46.177.43 ; # Remote ethernet 128.46.176.0 gateway 128.46.177.49 ; # Remote ethernet 128.46.182.0 gateway 128.46.177.50 ; # Remote ethernet 128.46.84.0 gateway 128.46.177.84 ; # Remote ethernet } ; # # Send out all sorts of interesting information in RIP packets # propagate proto rip { # # Propagate anything learned via RIP # proto rip ; # # Propagate static routes to county ethernets # Technically, the metric for remote ethernets should be 2, # but 1 works better in this scenario since there are no alternate # routes anyway, especially direct routes. # proto static metric 1 ; # # Propagate routes to all connected interfaces # # proto direct metric 1 ; } ; # # We don't have SNMP configured in # #snmp no ; We are using gated 2.1 and it is available via anonymous ftp from gated.cornell.edu in the file "pub/gated/gated/gated.tar.Z". It works quite well in our configuration. 7. Tuning You need to set up your "${DPCONF_DIR}/conf" file and any script and access files for what makes sense in your environment. The primary tuning comes in getting your dialing scripts to work, selecting appropriate timeouts in your access file, and monitoring what happens. The file ${DPLOG_DIR}/call.log can be used to give you a one line summary of each successful call. The file ${DPLOG_DIR}/dp.log can be used to show you a blow by blow description of calls in progress. The amount of logging can be increased by invoking dpd with "-d N" where N can be anywhere from 0 for minimal logging to 3 for verbose logging. In addition, the log level can be set for individual systems in the configuration file. If you encounter problems with the kernel modules, you can turn on very verbose debugging output by setting the following kernel variables: dpif streams module (dp_if.o) dp_if_debug General info dp_ftimo_debug Fast timeout mechanism dp_active_debug TCP connection status pppdial streams module (dp_if.o) ppp_dial_debug General info pppasync streams module (ppp_async.o) ppp_async_debug General info ppp_async_input_debug input packet dump of N bytes These variables are all "int" variables and should be set to 0 or 1, to have the reporting off or on, respectively. The ppp_async_input_debug variable can be given a value greater than 1 to indicate the number of bytes printed in a packet trace. When running adb on the kernel, you must be sure to specify the correct object file. If the modules are compiled into the kernel, the object module is always "/vmunix". Otherwise, the object module is the specific file ${DPMODULES_DIR}/dp_if.o or ${DPMODULES_DIR}/ppp_async.o For this example, we will use /vmunix, but please use the appropriate file depending on your configuration. Here is a typical adb session: # adb -w -k /vmunix /dev/mem physmem fe9 ppp_async_input_debug/X _ppp_async_input_debug: 0 /W0t32 _ppp_async_input_debug: 0x0 = 0x20 $q # In order to set a variable to remain in effect after the next reboot, you must use ? instead of /. 7.1 Broadcast programs Some programs broadcast information on a regular basis to all connected interfaces. If a program is found to generate frequent output on PPP interfaces, it should be reconfigured, modified, or just not run at all, depending on the circumstances. 7.1.1 rwhod A common example of a talkative program is rwhod. If you must run rwhod, it should be modified to ignore PPP links. Context diffs for rwhod are available on phoenix.acn.purdue.edu in pub/rwhod.diffs.Z. Once applying these diffs to rwhod sources, you should be able to run rwhod with the "-p" flag to suppress all output on Point to Point interfaces. 7.2 Nameserver If you are on the Internet, you are basically mandated to use DNS. If you are relying solely on DNS (no NIS or host tables), you should set up nameservers at the remote sites. Care should be taken in the configuration of the nameservers. There are at least a couple of ways that you can set things up. 7.2.1 Secondary nameservers You can set up secondary nameservers on each of the remote sites. They can zone load your organization wide zones on a regular basis. Please note that zones have a refresh time at which point a connection will be made to check for updates. This can vary, but it may be 12 hours or so. This interval is specified in the zone file on the primary nameserver. At this interval, the remote secondary nameserver will contact the primary nameserver (generating a call in our case). It will verify that it has the most recent version of each zone of interest. 7.2.2 Primary nameservers For remote sites that are placing toll calls, a refresh interval of 12 hours would result in 2 extra toll calls per day. This may be a problem. If so, consider making the remote system a primary nameserver. When the central nameserver file is updated, it needs distributed to all remote primary nameservers, but this may be manageable compared to all the long distance toll charges of the more automatic scheme employed by the secondary nameservers. In general the remote primary servers should not be listed in the nameserver data contained in the zone data. Otherwise, distant Internet hosts may try to use them for information about the zone, generating unnecessary traffic. They should exist as primary nameservers, but not be advertised as such. 8. Supporting Higher Baud Rates This software includes support for baud rates greater than 38400 in a few special circumstances. 8.1 Sun zs Ports The zs ports on the Suns are capable of going faster than 38400. The divisor in the hardware timer chip is set so that baud_rate = 4915200 / ((divisor + 2) * 2 * 16) Here are some example divisors Divisor Baud Rate 510 300 62 2400 14 9600 6 19200 2 38400 1 51200 0 76800 So, there is a little room for going faster. Unfortunately, there is not a 57600 baud rate available. However, some modems can handle 76800 (such as the Telebit Worldblazer), and that can be set just as easily. By default, the "-DFASTSZ" flag is set in the Makefile.hw file. So, code will be compiled into the program that will recognize 76800 as a valid baud rate. Since all 16 table entries are used up, we must replace one of the unused baud rate divisors with a 0 divisor. I have never seen anyone use 50 baud devices. The code that recognizes 76800, uses the table entry for 50 baud. In order to modify the kernel table for the zs divisors, use the following adb commands: # adb -w -k /vmunix /dev/mem zs_speeds/16d _zs_speeds: _zs_speeds: 0 3070 2046 1394 1140 1022 766 510 254 126 83 62 30 14 6 2 zs_speeds+2/w0 _zs_speeds+2: 0xbfe = 0x0 zs_speeds/16d _zs_speeds: _zs_speeds: 0 0 2046 1394 1140 1022 766 510 254 126 83 62 30 14 6 2 This modifies the in-memory copy only. To modify /vmunix, use ?w0. To modify for all future kernels, modify /usr/sys/`arch`/OBJ/zs_async.o 8.2 Central Data SCSIterminal Server Ports We use SCSI ports from Central Data of Champaign, IL, USA (1-217-359-8010). We have used the ST-1008 (8 port) and ST-1000 (16 port) models. They are capable of all the normal baud rates, plus 57,600 baud. Many V.32bis modems support 57600 baud, which is the theoretical baud rate maximum when using V.32bis + V.42 + V.42bis compression. To enable support for this device, edit the "Makefile.hw" file, and add the directive "-DSTS" to the HWSUPPORT definition. This is not defined by default, since using this software requires an include file that is not normally part of SunOS. The normal terminal driver designates 4 bits for speed, and all 16 possible speeds are already defined. So, Central Data has developed an ioctl which shifts the definition of all the baud rates down by one place in the table, making room for a new higher baud rate (57,600). This is extremely kludgy, but actually works quite well for us. You can issue this ioctl once, then use B38400. This is simpler in that it does not require code changes. However, you can get into a situation where the baud extension factor is set incorrectly, and nothing works right. Instead, we have modified the code that handles baud rate in all the software to recognize 57,600 and take appropriate action. This has been done in the dpd program. Using "-DSTS" in the Makefile will enable this support. If you want to run getty on this port, you will need to modify getty or provide a wrapper program that will set the baud rate extension factor correctly. You may also want to update tip or cu, as necessary. Some versions of the driver will output an annoying message on the console anytime the baud extension factor is set. If you have this driver, then you can turn that off with the following adb commands: # adb -w -k /vmunix /dev/mem physmem fe9 ctioctl+260/i _ctioctl+0x260: call _printf /W1000000 _ctioctl+0x260: 0x0 = 0x1000000 /i _ctioctl+0x260: nop $q # If the module is compiled into the kernel, you can do the same adb commands with a ? instead of / and make the changes in the compiled kernel. For a dynamically loaded driver, this will not work since the address of printf does not get set until the driver is loaded. Relocating the nop instruction will not produce the desired effect. 9. Future work A few areas are slated for future work as time permits. We will continue to track the Point to Point Protocol as it is updated and newer versions are made available With slow links, there are some problems with the combination of bursty interactive traffic and large batch file transfer traffic. A future release will implement Type of Service (TOS) priority queuing to give priority to interactive packets. This should help interactive response on heavily loaded links. We would like to add some administrative tools that can give a better picture of the traffic patterns over periods of time. For instance, it would be useful to have a report showing how many calls were placed for what protocol, sorted by number of calls, for a given month. Peter Galbavy is now working on modifications to do synchronous 64 Kbps with the SPARCstation on board serial port. Further updates to this document will be made as we get feedback from people using the software. Support for other platforms will be integrated as interested parties provide the ports. Support for Solaris 2.[12] will come as it becomes generally available. 9. Credits The bulk of the work has been done at Purdue University by Kirk Smith (ks@acn.purdue.edu) and has been supported by the Purdue Agricultural Computer Network. The Purdue ACN is responsible for networking 97 remote computers to the campus internet. Right now, 11 remote sites are in operation and more will come on line as Sun equipment is purchased. Peter Galbavy of Micromuse Ltd. (Peter.Galbavy@micromuse.co.uk) has provided invaluable help in several areas. Among these, were the loadable module support, integration of newer PPP revisions, significant work on this document, and much testing and several bug fixes.